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Abstract 

We  study  the  new  ANSI  C  type  qualifier  restrict,  which  allows  programmers  to  specify  pointers  that 
are  not  aliased  to  other  pointers.  The  main  contribution  of  this  paper  is  a  formal  semantics  for  restrict 
and  a  type  and  effect  system  for  checking  that  restrict-annotated  programs  are  correct  with  respect 
to  our  semantics.  We  give  an  efficient  inference  algorithm  for  our  type  system  and  describe  natural 
extensions  of  our  type  system  to  include  subtyping,  parametric  polymorphism,  and  affects  clauses  that 
capture  the  effects  of  calling  a  function.  We  also  discuss  ways  in  which  our  type  system  differs  from  the 
ANSI  C  standard. 


1  Introduction 

Almost  all  program  analyses  for  languages  with  pointers  must  perform  alias  analysis:  when  a  program 
indirectly  loads  or  stores  through  a  pointer  p,  the  analysis  must  determine  to  which  location(s)  p  points. 

The  research  literature  abounds  with  proposed  alias  analysis  techniques,  including  [LR92,  And94,  BCCH94, 
EGH94,  WL95,  Ste96,  DasOO],  some  of  which  scale  to  very  large  programs  [FFSA98,  RFOl,  HTOl].  Almost 
all  of  these  techniques  are  fully  automatic.  That  is,  the  analyses  take  a  bare  program  and  infer  all  possible 
aliasing. 

While  these  techniques  show  great  promise,  we  believe  that  alias  analysis  is  too  important  and  too  brittle 
to  be  left  entirely  to  the  compiler  (see  Section  1.3  for  two  examples).  In  this  paper,  we  study  restrict,  a  type 
qualifier  defined  in  the  new  ANSI  C  standard  (C99)  [ANS99].  Intuitively,  if  a  programmer  marks  a  function 
parameter  a;  in  a  C99  program  with  restrict,  then  a  compiler  may  assume — without  any  checking — that 
at  the  beginning  of  the  function,  no  other  paths  are  aliases  of  the  location  *x.  This  idea  harks  back  to 
the  semantics  of  FORTRAN.  The  FORTRAN  language  specification  states  that  if  the  programmer  passes 
an  array  to  a  function  multiple  times  under  different  names,  then  that  array  may  not  be  modified  by  the 
function,  and  it  is  up  to  the  programmer  to  enforce  this  requirement  [ANS78,  ABM+97].  The  qualifier 
restrict  tells  a  C  compiler  where  to  use  FORTRAN-style  semantics. 

We  believe  that  restrict  is  useful  in  any  language  with  updateable  references,  not  just  C.  In  this  paper, 
we  study  restrict  as  an  extension  to  the  A-calculus  with  updateable  references.  Our  version  of  restrict 
stays  close  to  the  definition  in  the  C99  standard  but  differs  in  some  respects,  discussed  in  Section  6.  We 
believe  that  our  study  of  restrict  in  a  concise  formal  system  helps  explain  the  C99  definition  and  may  be 
a  guide  to  future  revisions  of  the  standard. 

The  main  contributions  of  this  paper  are: 

•  We  formalize  restrict,  giving  it  a  precise  semantics  (Section  3). 

‘This  research  was  supported  in  part  by  NSF  CCR-9457812,  NASA  Contract  No.  NAG2-1210,  NSF  CCR-0085949,  and 
DARPA  Contract  No.  F33615-00-C-1693. 
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•  We  give  a  type  and  effect  system  [LG88]  for  checking  that  a  restrict-annotated  program  is  correct 
with  respect  to  our  semantics  (Sections  2  and  3). 

•  We  present  an  0{kn  +  na{n))  algorithm  (Section  4)  for  type  inference,  where  n  is  the  size  of  the  typed 
program,  k  is  the  number  of  restrict  annotations  in  the  program,  and  Q!(-)  is  the  inverse  Ackerman’s 
function. 

•  We  describe  three  natural  extensions  to  our  language:  subtyping  between  function  types  [TJ95],  para¬ 
metric  polymorphism,  and  an  affects  clause  for  describing  the  effects  of  calling  a  function  (Section  5). 

1.1  restrict 

Let  p  be  a  pointer  declared  as 

int  ^restrict  p; 

and  suppose  p  points  to  object  X.  Then  the  C99  standard  requires  that,  within  the  scope  of  p,  all  accesses 
to  X  are  through  the  name  p.^ 

The  qualifier  restrict  is  useful  because  it  allows  the  programmer  to  tell  the  compiler  that  certain 
pointers  are  never  aliased.  The  C99  specification  gives  the  following  example  code  illustrating  the  use  of 
restrict  ([ANS99],  page  111): 

void  f(int  n,  int  ^restrict  p,  int  ^restrict  q)  { 
while  (n —  >  0) 

3(cp++  =  *q++; 

} 

Here  because  the  types  of  p  and  q  are  annotated  with  restrict,  the  compiler  can  infer  that  *p  is  only 
accessed  through  the  name  p  and  *q  is  only  accessed  through  the  name  q,  and  thus  *p  and  *q  are  not 
aliased. 

1.2  Types  for  restrict 

We  check  the  correctness  of  restrict  annotations  using  a  type  and  effect  system.  Pointers  in  our  type 
system  are  given  types  of  the  form  re/^(r),  meaning  a  pointer  to  abstract  location  p,  where  abstract  location 
p  contains  a  value  of  type  r. 

Our  type  system  proves  judgments  of  the  form 

A  \-  e  :  T]  L 

where  L,  an  effect,  is  the  set  of  abstract  locations  the  evaluation  of  e  may  read  or  write.  Intuitively,  within  the 
scope  of  a  restrict-qualified  pointer  p,  we  cannot  dereference  any  aliases  of  p.  We  enforce  this  requirement 
with  constraints  of  the  form  p  ^  L,  which  holds  only  if  p  is  never  accessed  during  evaluation  of  e. 

Our  type  system  admits  an  efficient  inference  algorithm.  Our  type  inference  system  generates  constraints 
of  the  form  n  =  T2,  L  C  s,  and  p  ^  L,  where  e  is  a  variable  ranging  over  sets  of  effects.  As  stated  above, 
these  constraints  can  be  solved  in  0{kn  +  na{n))  time,  where  n  is  the  size  of  the  typed  program  and  k  is 
the  number  of  restrict  annotations  in  the  program. 

1.3  Applications 

We  briefly  outline  two  useful  applications  of  restrict. 

^The  ANSI  C  standard  actually  states  that  this  property  must  hold  only  if  X  is  modified  within  the  scope  of  p.  We  believe 
this  extra  condition  makes  the  definition  of  restrict  more  complicated  to  little  benefit  (see  Section  6). 
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Optimization.  As  mentioned  above,  restrict  was  added  to  the  C  standard  to  enable  compilers  to  recover 
non-aliasing  information  and  thus  to  optimize  pointer  accesses.  For  example,  given  the  code  for  function  f  () 
above,  a  compiler  can  use  the  assumption  that  *p  and  *q  are  not  aliased  to  reorder  the  assignments  in  the 
loop  across  iterations.  Without  restrict  annotations,  a  compiler  has  no  indication  of  the  programmer’s 
intention  (that  p  and  q  are  not  aliased),  and  the  programmer  has  no  way  to  indicate  that  a  compiler  should 
try  to  optimize  the  loop. 

In  the  C  standard  restrict  qualifiers  are  unchecked,  and  hence  there  is  no  guarantee  that  optimizations 
that  rely  on  restrict  are  valid.  If  a  program  using  restrict  type  checks  in  our  system,  however,  then  the 
restrict  annotations  are  guaranteed  to  be  correct  (up  to  the  usual  C  features  that  defeat  the  type  system, 
such  as  casting),  and  hence  optimizations  based  on  restrict  are  safe. 

Strong  Updates.  A  key  benefit  of  restrict  that  does  not  seem  to  be  anticipated  in  the  standard  is  local 
recovery  of  the  ability  to  perform  strong  updates  [CWZ90]  in  a  flow-sensitive  analysis.  Consider  the  following 
code  skeleton: 


void  foo(int  *x)  {...  ®  *x  =  e;  ©  . .  .} 

Here  ®  is  the  program  point  just  before  the  assignment  *x  =  e,  and  @  is  the  point  just  after  the  assignment. 
Assume  x  does  not  appear  to  the  left  of  ®. 

Suppose  we  perform  a  standard  forward  data-flow  analysis  on  this  program,  and  suppose  loc  is  our 
abstraction  for  the  location  that  x  points  to.  Let  [•]  be  our  interpretation  function  mapping  program  values 
and  expressions  to  abstract  values. 

There  are  two  ways  to  handle  the  assignment  to  *x.  If  we  know  that  loc  is  a  single,  unique  location,  then 
we  can  perform  a  strong  update  so  that  after  the  assignment 

Vocj^  =  le] 

On  the  other  hand,  if  loc  may  represent  more  than  one  memory  cell,  then  after  the  update  loc  summarizes 
locations  that  contain  both  old  and  new  information.  Therefore,  we  perform  a  weak  update,  and  after  the 
assignment 

[^oc]@  =  [e]  U  [;oc]0 

which  is  more  conservative. 

Suppose,  however,  that  x  is  declared  with  a  restrict  qualifier: 

void  foo(int  ^restrict  x)  {...  ®  *x  =  e;  @  . . .} 

Then  at  the  beginning  of  f  oo,  the  programmer  can  access  loc  only  through  the  name  x.  In  other  words,  out 
of  all  the  possible  run-time  locations  that  loc  represents,  by  adding  a  restrict  qualifier  the  programmer 
has  specified  that  the  body  of  foo  accesses  only  the  single  location  passed  as  the  argument  x. 

Therefore  within  the  body  of  foo  we  can  use  a  fresh  location  loc'  as  our  abstraction  for  the  location  x 
points  to.  Then  at  the  assignment  *x  =  e  we  can  perform  a  strong  update  on  loc'.  When  foo  returns  *x 
may  again  summarize  many  locations,  so  at  the  exit  of  foo  we  perform  a  weak  update  from  loc'  to  loc. 
Thus  restrict  lets  us  capture  a  common  mutual  exclusion  pattern  (see  Section  5). 

2  Language  and  Type  Checking 

We  present  our  type  system  for  restrict  using  an  extended  A-calculus.  For  example  uses  of  restrict,  see 
Section  5.  Section  6  discusses  the  issues  in  applying  these  ideas  to  C. 
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We  typecheck  the  following  language: 


e  ::=  v 

I  ref  e  Allocate  memory  initialized  to  e 
I  *  e  Dereference  pointer  e 

I  ei  :  =  e2  Assign  62  to  ei 
I  ei  62  Apply  function  ei  to  argument  62 
I  restrict  a;  =61  in  62 

Restrict  61  to  name  x  in  62 
V  ::=  X  Variable 

I  n  Integer 

I  Xx.e  Function 

Our  language  contains  a  new  scoping  construct 

restrict  a;  =61  in  62 


with  the  following  meaning:  x,  which  must  be  a  pointer,  is  initialized  to  61  and  bound  within  the  body  62. 
Within  62,  the  only  access  to  the  location  x  points  to  is  through  x  or  values  derived  from  x. 

In  C  terms,  the  expression  restrict  a;  =61  in  62  is  equivalent  to 

{  T  ^restrict  x  =  el; 
e2; 

} 

for  some  type  T. 

To  enforce  the  semantics  of  restrict,  our  type  system  needs  two  non-standard  features.  We  need  to 
explicitly  model  memory  locations,  and  we  need  to  track  which  locations  evaluation  may  access.  Our  type 
language  is  given  by  the  following  grammar: 

r  ::=  a  \  int  \  ref’ir)  \  ti  — ^  T2 

L  ::=  0  I  {p}  I  Li  U  L2  I  T  -  {p} 

The  base  types,  variables  a  and  an  integer  type,  are  standard.  Pointers  are  given  types  of  the  form  ref^{T), 
meaning  a  pointer  to  a  value  of  type  r.  The  p  is  an  abstract  location  naming  the  location  pointed  to.  In 
alias  analysis  terms,  p  can  be  thought  of  as  a  label  naming  a  location. 

Functions  are  given  types  of  the  form  ri  — >  T2 ,  meaning  a  function  with  domain  ri ,  range  T2 ,  and  effect 
L.  Effects  are  sets  of  locations.  Intuitively,  a  function  of  type  ri  T2  may  access  (read  or  write)  locations 
in  L  when  executed. 

Our  type  system  proves  judgments  of  the  form 

F  h  6  :  r;L 


meaning  that  expression  e  has  type  r  in  type  environment  F,  and  the  evaluation  of  e  may  read  or  write  the 
locations  in  L.  We  write  Iocs{t)  for  the  set  of  locations  occurring  in  the  type  r,  defined  as 


locs(a) 
locs(int) 
locs{ref  ^  (t)) 

Iocs{ti  T2) 


0 

0 

{p}  U  Iocs{t) 

Iocs(ti)  U  Iocs(t2)  U  L 


The  first  case,  locs{a)  =  0,  is  sound  for  our  monomorphic  type  system  because  a  represents  a  base  type.  See 
Section  5.3  for  a  discussion  of  this  case  for  a  polymorphic  type  system. 

We  define  locs{T)  as  U^  rer  Iocs{t).  In  proving  judgments,  our  type  system  uses  auxiliary  constraints  of 
the  form  p  ^  L  (notice  that  syntactically  the  set  Iocs{t)  can  be  considered  an  effect  L) ,  which  holds  if  p  does 
not  appear  in  the  set  L. 

Figure  1  gives  the  type  checking  rules  for  our  language.  We  briefly  discuss  the  rules. 
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r  ha;  :  r(a;);0 


(Var) 


r  h  n  :  int]  0 
r  h  e  :  r;L 


(Int) 


r  h  ref  e  :  ref^{T);L 
The:  ref^ir)]  L 


(Ref) 


(Deref) 


r  h  *  e  :  r;  L  U  {p} 

r  h  ei  :  re/^(r);  Li  F  h  62  :  r;  L2 
r  h  ei  :  =  62  :  r;  Li  U  1/2  U  {p} 

r[a;  n]  \-  e  :  T2',L 


(Assign) 


r  h  Xx.e  :  Ti 


r  h  61  :  Ti 


^2;  I/i 


(Lam) 

r  h  62  :  Ti ;  1/2 


r  h  61  62  :  r2 ;  I/i  U  1/2  U  L 

r  h  61  :  re/^(r);Li 
r[a;  HA  re/^  (r)]  h  62  :  r2;  1/2 

L2 _ p'  ^  Iocs{T,t,T2) 

r  h  restrict  x  =61  in  62  :  r2 ;  Li  U  L2  U  {p} 

rh6:r;L  pi, . . .  ,p„  ^ /ocs(r,r) 


(App) 


(Restrict) 


r  h  6  :  r;L  -  {pi, .  . .  ,p„} 


(Down) 


Figure  1:  Type  Checking  Rules 


•  (Var)  and  (Int)  are  standard. 

•  (Ref)  constructs  a  pointer  type.  Notice  that  p  is  unconstrained  in  this  rule,  because  initialization  is 
not  an  update  in  our  semantics. 

•  (Deref)  deconstructs  a  pointer  type.  Since  operationally  a  dereference  reads  a  location,  we  add  p,  the 
abstract  location  pointed  to  by  6,  to  the  effect  set. 

•  (Assign)  updates  a  location.  As  with  (Deref),  we  add  p  to  the  effect  set,  since  the  assignment  updates 
61.  Notice  we  require  that  the  type  of  62  and  the  type  pointed  to  by  61  match.  Since  those  types  may 
themselves  contain  abstract  locations  p,  this  rule  enforces  a  kind  of  may-alias  analysis  in  the  style  of 
Steensgaard  [Ste96]. 

•  (Lam)  constructs  a  function  type  with  effect  L,  the  effect  of  evaluating  the  function  body  e. 

•  (App)  deconstructs  a  function  type.  Notice  that  the  effect  of  61  62  includes  the  effect  of  evaluating  61, 
the  effect  of  evaluating  62,  and  the  effect  of  calling  the  function  61. 

The  key  rule  in  this  system  is  (Restrict).  Recall  that  the  semantics  of  restrict  a;  =61  in  62  state  that 
during  the  evaluation  of  62,  the  object  x  points  to  may  only  be  accessed  through  x.  To  enforce  this  rule  with 
types,  (Restrict)  binds  a;  to  a  type  with  a  fresh  abstract  location  p'.  With  this  binding  we  can  distinguish 
accesses  through  x  (or  values  derived  from  x),  which  have  an  effect  on  location  p',  from  accesses  through 
aliases  of  x,  which  have  an  effect  on  location  p.  Within  the  scope  of  62  only  accesses  through  x  are  allowed. 
Hence  the  constraint  p  ^  1/2- 
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The  final  hypothesis  of  (Restrict),  p'  ^  locs{T prevents  x  from  escaping  the  scope  of  e^.  Consider 
the  following  program: 

let  X  =  ref  0  in 
let  p  =  ...  in 

(restrict  q  =  x  in 

p  :=  q; 

restrict  r  =  x  in 

**p) 

Suppose  X  has  type  re/^*  {ini).  By  (Restrict),  the  types  of  q  and  x  can  contain  different  abstract  locations.  Let 
q’s  type  be  re/^’  (ini),  where  px  Pq-  Now  if  the  clause  p'  ^  locs{T,  r,  T2)  were  not  included  in  the  hypothesis 
of  (Restrict),  the  assignment  p  :=  q  would  typecheck.  At  program  point  ®,  we  would  have  two  different 
names  for  the  same  location — p^  and  px — even  though  neither  is  restricted.  Thus  the  dereference  **p 
would  typecheck  even  though  the  program  is  semantically  invalid.  We  forbid  p'  from  escaping  in  (Restrict) 
to  prevent  this  problem. 

An  alternative  formulation  is  to  use  a  flow-sensitive  type  system,  where  in  (Restrict)  x  is  given  the  type 
ref^  (r)  within  e2’s  scope,  and  escaping  occurrences  of  x  are  given  the  type  ref^{T)  after  the  restrict.  We 
did  not  pursue  this  strategy  because  it  is  significantly  more  complex,  and  to  be  useful  restrict  must  be 
easily  understood  by  programmers. 

Finally,  notice  that  the  conclusion  of  (Restrict)  contains  the  effect  {p},  i.e.,  restricting  a  location  is  itself 
an  effect.  This  naturally  forbids  the  following  program: 

restrict  y  =  x  in 
restrict  z  =  x  in 

*y 

The  last  rule,  (Down),  states  that  effects  on  any  non-escaping  location  can  be  removed  from  the  effect 
set  [GJLS87,  LG88,  CalOl].  The  rule  (Down)  is  the  one  non-syntactic  rule  in  our  system.  We  can  construct 
a  purely  syntax-directed  version  of  our  system  by  incorporating  down  into  the  type  rules. 

Lemma  1  A  proof  o/T  h  e  :  r;  L  can  be  rewritten  to  contain  at  most  one  occurrence  of  (Down)  in  sequence. 

Lemma  2  A  proof  of  T  \-  e  :  t;  L  can  be  rewritten  so  that  the  only  uses  of  (Down)  are  as  the  final  step  in 
the  proof,  the  hypothesis  of  (Lam),  or  the  62  hypothesis  of  (Restrict). 

Proof:  All  rules  except  (Down),  (Lam),  and  (Restrict)  are  monotonic  in  their  effects.  That  is,  for  each  rule 
except  (Down)  and  (Lam)  the  set  of  effects  in  the  conclusion  is  a  superset  of  all  the  sets  of  effects  in  the 
hypotheses.  Now,  for  any  effect  sets  L  and  L'  we  have 

(L  -  {pi,...,pn})  UL'  =  (LUL')  -  {pp,...,p*„} 

where 

=  {pi,--,Pn}  n  -iL' 

Thus  we  can  always  move  a  use  of  (Down)  above  one  of  the  hypotheses  below  the  conclusion. 

In  (Restrict),  we  can  move  uses  of  (Down)  from  above  the  ei  hypothesis  to  below  the  conclusion.  We 
cannot  move  arbitrary  uses  of  (Down)  from  above  the  62  hypothesis  because  of  the  constraint  p  ^  L2.  □ 
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I  e  dom{S) 

Shl^l^S 


[Var/Loc] 


S  \-  n  ^  n\S 


[Int] 


S  \-  e  ^  V,  S'  I  ^  dom{S') 
S  h  ref  e  ^  l\  S'\l  ^  v\ 


5  h  e  ^  5'  /  G  dom{S') 

Sh  S'{l)-,S' 


[Deref] 


5  h  ei  ^  5'  5'  h  ea  ^  v,  S" 

I  G  dom{S")  S"{1)  ^  err 
5  h  ei  :  =  62  v;  S"[l  1;] 


[Assign] 


S  h  Xx.e  Xx.e;  S 


[Lam] 


5  h  61  ^  Aa;.e;  5'  S'\-e2^v,S" 

S"\-e[x^v] 

5  h  61  62  -^v';S'" 


[App] 


5h6i 

S'[l  HA  err,  I'  ha  S'{1)]  h  62[a;  ha  I']  v,  S" 
I  G  dom{S')  I'  ^  dom{S') 

S  h  restrict  a;  =6i  in  62 

v,S"[l  HA  HA  err] 


[Restrict] 


Figure  2:  Big-Step  Semantics 


Based  on  these  two  lemmas,  we  can  eliminate  (Down)  and  incorporate  it  into  (Lam)  and  (Restrict): 


r[a;  HA  Ti]  I-  6  :  r2;  L 

pi,...,Pn^  Iocs{T,ti,T2) 
L'  =  L  -  {pi,  Pn} 

r  I-  Xx.e  :  Ti  r2;  0 


(Lam') 


r  h  61  :  re/^(r);Li 
r[a;  HA  ref  (r)]  h  62  :  r2;  L2 
pi,...,Pn^  Iocs{t,  r,  r2)  U  {p'} 

L'2  =  L2  —  {pi,  .  .  .  ,Pn} 

p  ^  L'2  p'  ^  IoCs(T,T,T2) 

r  |-  restrict  x  =61  in  62  :  r2 ;  Li  U  L2  U  {p} 


(Restrict') 


3  Semantics  and  Soundness 

Figure  2  gives  a  big-step  operational  semantics  for  our  language.  Judgments  are  of  the  form  S  e  ^  v,  S' , 
meaning  that  given  store  S  (a  map  from  locations  to  values) ,  expression  e  evaluates  to  value  v  and  new  store 
S'.  Values  are  locations,  integers,  and  functions.  We  implicitly  assume  that  if  5  h  6  u;  5'  is  not  provable 
by  the  rules  then  5  h  6  err;  S.  The  token  err  is  not  a  value. 

Notice  that  our  semantics  contains  no  environment  for  variables.  We  use  substitution  to  bind  variables 
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to  values.  Locations  are  bound  in  the  store  to  either  values  or  err. 

We  only  discuss  two  interesting  features  of  the  rules.  First,  [Assign]  has  a  surprising  case:  We  need  to 
check  whether  S''{1)  is  err  before  updating  location  1.  We  do  not  need  to  check  for  this  explicitly  in  [Deref], 
because  the  semantics  are  strict  in  err.  However,  because  [Assign]  does  not  examine  the  contents  of  I,  we 
need  to  add  this  check. 

Second,  [Restrict]  uses  copying  to  enforce  restrict’s  semantics.  To  evaluate  restrict  a;  =ei  in  62,  we 
first  evaluate  ei  normally,  which  must  yield  a  pointer  1.  Within  the  body  of  62,  the  only  way  to  access  what 
I  points  to  should  be  via  the  particular  value  that  resulted  from  evaluating  ei.  We  enforce  this  by  allocating 
a  fresh  location  I'  initialized  with  the  contents  of  I,  and  then  binding  I  to  err  to  forbid  access  through  1. 
Recall  that  because  our  semantics  is  strict  in  err,  any  program  that  dereferences  I  within  62  will  result  in 
err. 

The  soundness  of  our  type  system  (see  below)  implies  that  no  program  evaluates  to  err,  which  in  turn 
implies  that  an  implementation  can  safely  optimize  restrict  by  eliding  the  copy  of  1.  Instead,  in  an 
implementation  restrict  simply  binds  x  to  1. 

Notice  it  is  not  an  error  to  use  the  value  I,  but  only  to  dereference  it.  When  62  has  been  evaluated  we 
re-initialize  I  to  point  to  the  value  x  points  to,  and  then  forbid  accesses  through  I'.  Forbidding  access  through 
I'  corresponds  to  the  requirement  in  the  type  rule  (Restrict)  that  p'  not  escape.  An  alternative  formulation 
is  to  rename  occurrences  of  I'  to  I  after  62  finishes.  We  could  write  this  style  of  rule  in  a  small-step  semantics. 

3.1  Soundness 

We  next  sketch  a  proof  of  soundness.  In  our  proof,  we  implicitly  extend  typing  judgments  to  semantic  values 
in  the  following  way.  Locations  I  are  represented  in  the  proof  as  program  variables,  and  thus  their  types 
are  stored  in  F  and  they  typecheck  using  (Var).  We  implicitly  treat  evaluated  and  unevaluated  integers 
identically  and  use  (Int)  to  typecheck  both.  Functions  are  represented  not  as  closures  but  as  syntactic 
functions,  as  in  standard  small-step  semantics  subject-reduction  proofs  [WF94,  EST95].  Thus  evaluated 
functions  are  typechecked  using  (Lam). 

To  show  soundness  we  first  show  a  subject-reduction  result.  We  begin  by  introducing  a  notion  of  com¬ 
patibility  to  capture  when  it  is  safe  to  evaluate  an  expression. 

Definition  1  (Compatibility)  We  say  F  and  L  are  compatible  with  store  S,  written  (F,  L)  ~  S,  if 

1.  dom(T)  =  dom(S)  and 

2.  for  all  I  e  dom(S),  there  exist  p,T  sueh  that  r(/)  =  ref’ir)  and 

F  h  S{1)  :  r;  0  if  S{1)  ^  err 
p  ^  L  if  S{1)  =  err 

Intuitively,  (F,  L)  ~  5  if  an  expression  e  that  typechecks  in  environment  F  and  has  effect  L  can  execute 
safely  in  store  S.  Notice  that  the  definition  of  compatibility  requires  doni{T)  =  dom{S),  i.e.,  that  expressions 
typed  in  environment  F  may  contain  locations  but  not  other  free  variables.  This  property  is  maintained 
during  evaluation  because  in  [App]  we  implement  function  call  with  substitution. 

As  evaluation  progresses  the  proof  of  subject  reduction  extends  F  with  new  locations  allocated  by  ref 
expressions.  It  is  a  property  of  our  semantics  and  type  system  that  these  additions  to  F  are  safe,  in  the 
following  sense: 

Definition  2  (Safe  Extension)  We  say  that  (F',  S')  is  a  safe  extension  of  (F,  S),  written  (F,  S)  {V ,S'), 

dom(T)  =  dom(S)  and  dom(T')  =  dom(S'), 

^  Idom(r)  “ 


3.  for  all  I  e  dom{S')  —  dom{S),  if  S'{1)  =  err  and  T'{1)  =  ref''{T),  then  p  ^  loes{T),  and 


4-  for  all  I  e  dom{S),  if  S'{1)  =  err  then  S(l)  =  err. 

Here  restriction  of  F'  to  the  domain  of  F.  Intuitively,  (F,5)  (F',5')  if  the  err-bound 

locations  in  S'  are  either  also  err-bound  in  5,  or  if  they  are  fresh  (do  not  appear  in  F). 

With  these  definitions  we  can  state  our  subject-reduction  theorem.  We  use  r  to  stand  for  a  semantic 
reduction  result,  either  a  value  v  or  err. 

Theorem  1  (Subject  Reduction)  7/  F  h  e  :  r;  L  and  S  \-  e  ^  r;  S' ,  where  (F,  L  U  L')  ~  S  for  some  L' , 
then  there  exists  F'  sueh  that 

1.  F'  h  r  :  r;  0  (whieh  implies  r  ^  err), 

2.  {T',L')  ~  S',  and 

3.  (F,5)  ^  (F',5') 

Proof  (Sketch):  By  induction  on  the  structure  of  the  derivation  5  h  e  r;5'.  The  interesting  case  is 
restrict  a;  =ei  in  62. 

By  assumption,  we  know 

F  h  ei  :  re/^(r);  Li 
F[a;  ref  (r)]  h  62  :  r2;  7/2 

L2 _ p'  ^  loes{T,T,T2) 

F  h  restrict  x  =ei  in  62  :  r2 ;  7/i  U  7/2  U  {p} 

We  also  have  S  h  restricta;  =ei  in 62  r;5'.  By  inspection  of  the  semantic  rules,  this  reduction  must 

have  contained  a  reduction  of  ei : 

S\-  e\  Tei ;  5' j 

We  apply  induction  to  show  that  there  exists  a  F^^  satisfying 

1.  F(j  h  rei  :  re/^(r);0 

2.  (F(^,L2U{p}UL')~^; 

3.  (F,5)^(F(^,5;) 

After  this  step,  though,  we  cannot  directly  apply  induction  to  the  evaluation 

5'ei  [rei  ^  err,  5' ^  (r^i )]  h  62  [a;  i-^-  I']  ;  5',^ 

of  62.  The  problem  is  that  we  would  need  to  show  the  following  compatibility: 

(r' j ,  L2  U  {p}  U  L')  r.  5' j  [re,  ^  err,  I'  ^  5' ^  (re, )] 

But  of  course  this  compatibility  does  not  hold,  because  rg,  maps  to  err.  We  can  solve  this  problem  by 
simply  removing  p  from  the  effect  set.  But  there  is  a  deeper  problem:  although  I'  is  fresh,  p'  may  not  be, 
and  thus  there  may  be  some  location  I"  such  that  T'^^{1")  =  ref  (r)  and  S'e,{l")  =  err. 

To  solve  this  problem,  we  observe  that  the  name  p'  is  arbitrary.  We  construct  a  substitution  7?  =  [p'  i-^-  p"] 
for  some  fresh  p" .  Then  from 

F[a;  ref  (r)]  1-62  :  r2;  7/2 

we  conclude 

7?(F[a:  ^  ref'f)])  h  62  :  7?(r2);  7?(L2) 

Then  using  the  hypothesis  p'  ^  /ocs(F,r, r2)  in  the  type  rule  (Restrict),  we  derive 

F[a;  ref  (r)]  h  62  :  r2;  7?(L2) 
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r,  er  I-  a;  :  r(a;);  0 


(Var) 


r,  er  1“  n  :  int]  0 


(Int) 


r,er  1“  e  :  r;  L  p  fresh 
r,er  h  ref  e  :  ref^{T)-,L 


(Ref) 


r,  er  h  e  :  r;  L  r  =  ref^{a)  p,  a  fresh 
r,  er  h  *  e  :  r;  L  U  {p} 


(Deref) 


r,er  h  ei  :  Ti;  Li  r,er  h  62  :  r2;  1/2 
Ti  =  re/^(r2)  p  fresh 

r,  er  h  ei  :  =  62  :  r2 ;  Li  U  L2  U  {p} 


(Assign) 


r[a;  HA  Q!],er[a;i-i.a]  e:T2',L  a,e  fresh 

er  U  locsio^  C  SY[xi-^a] 

L  n  (er[a;i^a]  u  Iocs{t2))  C  e 

r,  er  h  Aa;.e  :  a  T2]  0 


(Lam) 


r,er  h  ei  :  Ti;  Li  r,er  h  62  :  r2;  1/2 
Ti  =  T2  — >  a  a,e  fresh 

r,  er  h  ei  62  :  T2;  Li  U  L2  U  e 


(App) 


r,er  h  ei  :  ri;Li  Ti  =  ref^{a) 

r',er'  h  62  :  r2;I/2  T'  =  r[a;  ha  ref^  (a)] 
er  U  {p'}  U  locs{a)  C  er- 
1/2  n  (er'  U  Iocs(t2))  C  e 
p  ^  e  p'  ^  er  U  locs{a)  U  Iocs{t2) 

p,  p' ,  a,  e  fresh 

r,  er  h  restrict  x  =ei  in  62  :  r2 ;  Li  U  e  U  {p} 


(Restrict) 


Figure  3:  Type  Inference  Rules 


Now  we  can  show  the  following  compatibility: 

(F;^  ,  R{L2)  U  (L'  -  {p}))  ~  5;  K,  ^  err,  I'  ^  (r,, )] 

and  thus  apply  induction  to  the  evaluation  of  62- 

We  apply  the  same  renaming  trick  to  uses  of  (Down) .  Because  pi , 
names  are  arbitrary  and  we  can  freely  rename  them. 

Given  the  subject-reduction  theorem,  soundness  is  easy  to  show: 

Corollary  1  7/  0  h  e  :  r;  L,  then  0  h  e  r;  5',  where  r  is  not  err. 

Proof:  First  observe  that  (0,  L)  ^  0.  Then  in  our  semantics  every  term  can  be  reduced  to  some  result  r. 
By  the  subject-reduction  theorem,  there  is  a  F'  such  that  F'  h  r  :  r;  0.  Thus  r  is  not  err.  □ 


■  ■  ■  ,Pn  do  not  escape  in  (Down) ,  their 

□ 


4  Inference 

Figure  3  gives  the  type  inference  rules  for  our  system.  Our  type  rules  generate  three  kinds  of  constraints 
C,  equality  constraints  between  types,  inclusion  constraints  between  effects,  and  disinclusion  constraints 
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between  locations  and  effects: 


C  ::=  Ti  =  r2  I  L  C  e  I  p  ^  L 
r  ::=  a  \  int  \  ref^ir)  \  ti  — ^  T2 
L  ::=  0  I  {p}  I  e  I  Li  U  L2  I  n  L2 

Here  e  is  an  ejfect  variable.  Notice  that  inclusion  constraints  between  effects  are  of  the  special  form  L  C  s, 
which  makes  these  constraints  particularly  convenient  to  solve. 

In  addition  to  the  type  environment  F,  during  type  inference  we  construct  effect  variables  er  to  contain 
the  set  of  effects  occurring  in  environment  F.  As  we  extend  environment  F  with  a  new  binding  x  ^  t  m 
(Lam)  and  (Restrict),  we  generate  a  constraint 

er  U  Iocs{t)  C  £r[x^r] 

In  this  way  we  succinctly  capture  the  set  locs{T)  without  needing  an  explicit  linear  pass  through  F.  We 
briefly  discuss  the  rules. 

•  (Var)  and  (Int)  are  identical  to  the  type  checking  rules  except  for  the  addition  of  er  to  the  left  of  the 
turnstile. 

•  (Ref),  (Deref),  (Assign),  and  (App)  are  written  with  explicit  fresh  variables  and  equality  constraints 
between  types. 

•  (Lam)  incorporates  (Down)  according  to  Lemmas  1  and  2.  Notice  that  we  express  (Down)  as  an 
intersection  property.  Also  notice  that  function  types  always  have  an  effect  variable  e  on  the  arrow. 
In  this  way  when  we  propagate  equality  constraints  on  types  to  equality  constraints  on  effects,  we  will 
always  yield  equalities  between  effect  variables  rather  than  between  arbitrary  effects. 

•  (Restrict)  also  incorporates  (Down),  written  as  an  intersection  property.  (Restrict)  is  the  only  rule 
that  generates  constraints  of  the  form  p  ^  L. 

Let  m  be  the  size  of  the  initial  program.  Applying  the  type  inference  rules  in  Figure  3  takes  0(m)  time 
and  generates  a  system  of  constraints  C  of  size  0{m). 

We  split  the  resolution  of  the  side  constraints  C  into  two  phases.  First,  we  apply  unification  to  solve  the 
type  equality  constraints  ri  =  Figure  4a  gives  the  type  unification  algorithm  as  a  series  of  left-to-right 
rewrite  rules.  This  step  can  be  completed  in  0{ma{m))  time,  where  a{-)  is  the  inverse  Ackerman’s  Function. 

After  this  first  step,  we  replace  the  sets  Iocs{t)  by  the  set  of  locations  contained  in  r  (defined  in  Section  2). 
Let  n  be  the  size  of  the  program  annotated  with  standard  types.  Notice  that  substituting  for  the  sets  Iocs{t) 
takes  time  0(n),  and  the  resulting  constraint  system  is  size  0(n),  because  of  our  restriction  that  arrows  are 
always  annotated  with  effect  variables. 

The  resulting  constraints  are  of  the  form  L  C  e  and  p  ^  L.  We  call  such  a  system  of  constraints  an  ejfect 
constraint  system.  A  solution  to  an  effect  constraint  system  C  is  a  mapping  a  from  effect  variables  to  sets 
of  locations  such  that  a{L)  C  a{£)  and  p  ^  o{L)  for  each  constraint  L  C  s  and  p  ^  Lm  C,  where  we  extend 
(T  from  effect  variables  to  arbitrary  effects  in  the  natural  way.  An  effect  constraint  system  is  satisfiable  if 
it  has  a  solution.  Notice  that  abstract  locations  are  not  in  the  domain  of  a — intuitively,  after  applying  the 
rules  of  Figure  4a,  we  treat  abstract  locations  as  constants. 

We  define  a  partial  order  on  solutions,  a  <  a'  iS  for  every  effect  variable  e  we  have  (T(e)  C  (T'(e).  The 
least  solution  to  an  effect  constraint  system  is  the  solution  a  such  that  a  <  a'  for  any  other  solution  a' . 

Lemma  3  If  ejfect  constraint  system  C  has  a  solution,  then  C  has  a  least  solution. 

Proof:  Let  E  be  any  set  of  solutions  of  C.  We  claim  that  PIctgi:  ^  ^  solution  of  C,  where  (PIctgs  cr)(e)  = 

PlaGS  '^(^)-  Suppose  C  contains  a  constraint  p  ^  L.  Then  by  assumption  for  all  cr  €  E  we  have  p  ^  o{L). 
Thus  it  must  be  that  p  ^  flaGS  Suppose  C  contains  a  constraint  L  C  s.  Then  by  assumption  for  all 

(T  e  E  we  have  a(L)  C  a(£).  But  then  (PI^gs  —  (PlaGS 

Then  since  (flaGS  ^  cr  €  E,  the  set  of  solutions  of  C  has  a  least  element.  □ 
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C  U  {a  =  r}  C[a  r] 

C  U  {int  =  int\  C 
C  U  {re/^'  (n)  =  re/^"  {T2)} 

CU{pi  =  P2}  U  {ri  =  T2} 

C  U  {ri  ^  T2  =  t[  Tj} 

C  U  {n  =  rj}  U  {t2  =  Tj}  U  {e  =  e'} 
C  U  {other  type  eqn)  unsatisfiable 

C  U  jpi  =  P2}  C\pi  P2] 
C  U  {£1  =  £2}  ^  (^[£1  '“t  £2] 

(a)  Type  Unification 


C*  U  Ip  ^  L} 

C  U  Ip  ^  £}  U  {L  C  £}  £  fresh 

C  U  {0  C  £}  ^  C 

C  U  {Li  U  L2  C  £}  C  U  {Li  C  £}  U  {L2  C  £} 

C'U{0nLC£}  C 

C'u{Ln0C£}  c 

CU  {(Li  U  L2)  n  L  C  £} 

C  U  {£'  n  L  C  £}  U  {Li  U  1/2  C  £'}  e'  fresh 
CU  {Ln  (Li  U  L2)  C  £} 

C  U  {L  n  £'  C  £}  U  {Li  U  1/2  C  £'}  e'  fresh 


(b)  Constraint  Normalization 


Figure  4:  Constraint  Resolution 


To  test  satisfiability  of  an  effect  constraint  system,  we  first  apply  the  rules  in  Figure  4b  to  translate  the 
constraints  into  the  following  normal  form: 

C  ::=  L  C  £  \  p  ^  £ 

M  ::=  {p}|£ 

L  ::=  M\MnM 

Notice  that  the  rules  in  Figure  4b  preserve  least  solutions  but  not  arbitrary  solutions.  Also  notice  that  in 
Figure  4b  we  do  not  consider  the  case  (I/inl/2)nl/  C  £  or  Ln(I/inl/2)  C  £.  Inspection  of  the  rules  of  Figure  3 
shows  that  constraints  with  nested  intersections  are  never  generated.  Applying  the  rules  in  Figure  4b  takes 
time  0{n). 

We  view  the  inclusion  constraints  in  a  normal  form  effect  constraint  system  as  a  directed  graph: 


Constraint 

Edge(s) 

MC£ 

p  ^  £ 

£1  C  £2 

£1  £2 

Ml  n  M2  c  £ 

Ml  ^  n 
M2  -i-n 
n  —>  £ 

The  nodes  of  the  directed  graph  are  abstract  locations  p  (with  in-degree  0) ,  effect  variables  £  (with  arbitrary 
in-degree) ,  and  intersections  fl  (with  in-degree  2) .  We  generate  a  fresh  n  node  for  each  constraint  Mi  n  M2  C 

£. 

Given  a  normal  form  effect  constraint  system,  we  test  satisfiability  by  checking,  for  each  constraint  p  ^  £, 
whether  p  £  S{£)  in  the  least  solution  S.  Figure  5  shows  the  modified  depth-first  search  we  use  to  check  this 
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Associate  a  count  C{v)  with  each  node  v  in  the  graph 

Initialize  C{v)  =  0  for  all  v 

Let  W  =  {p},  the  set  of  nodes  left  to  visit 

While  W  is  not  empty 

Remove  some  node  v  from  W 
If  V  ==  e  return  unsatisfiable 
For  each  edge  v  ^  e' 

If  C'(e')  ==  0  then 
C{e')  =  1 
Add  e'  to  W 
For  each  edge  n  n 
If  C'(n)  ==  0  then 
f7(n)  =  1 

If  C'(n)  ==  1  then 
(7(0)  =  2 
Add  n  to  LF 

Return  satisfiable 


Figure  5:  Checking  satisfiability  of  p  ^  e 

condition.  The  algorithm  in  Figure  5  takes  time  0{n)  for  each  p  ^  e  constraint.  Given  an  initial  program 
with  k  occurrences  of  restrict,  the  system  considered  in  Figure  5  will  have  0{k)  constraints  of  the  form 
p  ^  e.  Hence  the  total  time  for  this  step  is  0{kn). 

Therefore  the  total  time  for  this  algorithm  is  0{ma{m)  +  kn).  Given  that  the  typed  program  is  strictly 
larger  than  the  untyped  program,  the  algorithm  runs  in  time  0{na{n)  +  kn),  where  n  is  the  size  of  the 
program  annotated  with  standard  types. 

5  Examples  and  Extensions 

We  present  some  small  examples  that  illustrate  interesting  features  of  our  type  system  for  restrict.  We 
write  our  examples  in  C,  and  unless  otherwise  specified  the  behavior  of  each  usage  in  our  type  system  matches 
C99. 

The  obvious  application  of  restrict  is  to  control  the  name  through  which  a  location  is  accessed.  For 
example,  consider  the  following  code: 

{  int  ^restrict  p  =  q; 

*p;  //  valid 

*q;  //  invalid 

} 

Since  p  is  annotated  with  restrict,  we  may  dereference  p  but  we  may  not  dereference  q. 

As  another  example,  consider  the  following  code,  which  shows  how  restrict-qualified  pointers  may  be 
passed  from  outer  to  inner  scopes: 

{  int  ^restrict  p  =  . . . ; 

{  int  ^restrict  r  =  p; 

*r;  //  valid 
*p;  //  invalid 

} 

*p;  //  valid 

} 

Here  within  the  scope  of  r  we  can  dereference  r  but  not  p,  and  when  r  goes  out  of  scope  we  recover  the 
ability  to  dereference  p. 
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As  another  example,  consider 

{  int  ^restrict  p  =  . . . ; 
int  *r  =  p ; 

*r;  //  valid 

} 

Notice  that  binding  p  to  r  actually  writes  the  value  of  p  to  memory  (r  is  an  1-value).  In  this  case,  within 
the  scope  of  p  our  type  system  allows  us  to  store  and  retrieve  the  value  of  p  from  memory  as  long  as  that 
memory  does  not  escape  the  scope  of  p.  This  particular  example  is  not  allowed  by  the  C  standard. 

The  rule  (Down)  allows  us  to  distinguish  restricted  locations  in  different  instances  of  the  same  function. 
For  example,  consider  the  following  code: 

void  foo(void)  { 
int  a; 

int  ^restrict  p  =  &a; 
foo()  ;  //  valid 

*p  =  3;  //  valid 

} 

Because  a  is  purely  local  to  the  body  of  foo(),  applying  (Down)  removes  the  effect  on  a  from  the  effect  set 
of  foo().  Thus  foo()  does  not  have  any  visible  effect,  and  calling  foo()  within  the  scope  of  p  is  valid. 

One  of  the  most  interesting  properties  of  restrict  is  that  it  lets  us  recover  non-aliasing  information 
from  complicated  aliasing  conditions.  For  example,  consider  the  following  code: 

{  lock  ^restrict  1  =  a[i]->lock; 
spin_lock(l) ; 

spin_unlock(l) ; 

} 

In  a  standard  type  system  all  elements  of  an  array  have  the  same  type.  Thus  in  this  example  the  pointer 
1  may  point  to  a  large  set  of  possible  locations.  Recall  from  the  introduction  that  restrict  gives  us  the 
ability  to  temporarily  recover  strong  updates.  Thus  even  though  1  may  point  to  a  large  number  of  possible 
locks,  by  annotating  the  type  of  1  with  restrict  the  programmer  has  guaranteed  that  they  only  access  one 
particular  lock  within  the  scope  of  1.  Thus  using  a  standard  data-flow  analysis  we  can  treat  the  calls  to 
spin_lock  and  spin_unlock  as  strong  updates  and  successfully  check  whether  this  piece  of  code  adheres  to 
a  standard  locking  protocol  (e.g.,  spin_lock  is  never  called  twice  in  a  row  on  the  same  lock). 

5.1  affects  Clauses 

Our  notation  includes  effect  sets  L  on  function  types  ri  T2  ■  Clearly  if  we  wish  to  apply  our  type  system 
to  real  source  code,  we  need  some  notation  for  annotating  function  types  with  these  effect  sets. 

One  natural  design  is  to  use  syntax  similar  to  Java  exceptions.  We  allow  functions  to  be  declared  with 
affects  clauses  of  the  form 

void  foo(int  **x)  affects  *x,  **x; 

In  our  type  system,  x  is  given  a  type  of  the  form 

ref  ^ {ref  ^  {int)) 

The  affects  clause  means  that  foo()  should  be  given  the  type 

ref '’{ref’  {int))  void 

The  type  checker  incorporates  this  notation  by  using  the  declared  effect  set  of  f  oo  wherever  f  oo  is  used. 
When  the  typechecker  types  the  body  of  foo  and  computes  its  effect  L,  it  verifies  that  L  =  {p,p'},  i.e.,  that 
the  declared  type  was  valid. 
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5.2  Subtyping 


We  can  extend  our  type  and  effect  system  to  admit  a  form  of  subtyping  among  function  types  [G  JLS87,  TJ95] . 
Given  our  type  system,  it  is  natural  to  add  a  rule  of  the  form 


and  to  add  subsumption 


r  h  e  :  r;  L  r  <  r' 
r  h  e  :  r' 


(Sub) 


to  the  typing  rules. 

Sub  typing  increases  the  usefulness  of  the  type  system  in  two  ways.  First,  more  programs  will  typecheck 
with  subtyping.  Second,  subtyping  makes  affects  clauses  easier  to  write.  Since  the  programmer  is  likely 
not  to  annotate  functions  with  exactly  the  right  set  of  effects,  if  we  incorporate  sub  typing  then  instead 
of  requiring  that  the  declared  effect  L'  or  a  function  match  exactly  the  inferred  effect  L,  we  can  require 
L'  D  L.  Our  subject  reduction  and  soundness  theorems  from  Section  3  both  hold  in  a  system  with  (Sub). 
Our  inference  algorithm  can  also  be  easily  adapted  to  admit  subsumption. 


5.3  Parametric  Polymorphism 


Our  type  and  effect  system  can  also  be  extended  with  parametric  polymorphism.  Function  types  are  extended 
to  polymorphically  constrained  types 

r  ::=•••  I  Vpe.ri  T2\C 

Here  p  are  the  generalized  abstract  locations,  e  are  the  generalized  effect  variables,  and  G  is  a  collection 
of  constraints  of  the  form  p  ^  L,  p  ^  locs{T),  and  p  ^  Iocs{t).  The  type  rules  are  rewritten  to  track  the 
constraints  generated  in  each  sub-proof,  e.g.. 


r,Gh  ei  :  re/^(r);Li 
r[a;  ref  (r)],G  h  62  :  r2;  L2 
C  \-  p  ^  L2  C  \-  p'  ^  locs{T,  T,  T2) 

r,G  h  restrict  a;  =ei  in  62  :  r2;  Ti  U  1/2  U  {p} 


(Restrict) 


We  add  the  standard  rules  for  quantification  and  instantiation: 


r,GI-e:r;I/  pf^locs{T) 
F,  G  h  e  :  'ipe.fC 


(Poly) 


F,  G  h  a;  :  \fps.T\C'  C  h  RC 
R  =  [p  1-^  p' ,£  1-^  e'] 

F,  G  h  a;  :  i?r 


(Inst) 


We  restrict  generalization  to  function  types,  as  is  standard  [Wri95]. 

If  we  also  allow  type  polymorphism  in  addition  to  location  and  effect  polymorphism,  then  in  (Restrict) 
we  may  need  to  check  constraints  of  the  form  p  ^  locs{a)  for  some  type  variable  a  generalized  in  (Poly) .  In 
this  case  we  cannot  define  locs(a)  =  0,  since  a  may  be  instantiated  with  a  re/ type  at  some  point.  Instead, 
we  carry  the  sets  locs{a)  syntactically  in  the  polymorphically  constrained  types  and  expand  them  when  the 
type  variables  a  are  instantiated. 

We  believe  our  soundness  proof  can  be  easily  adapted  to  admit  parametric  polymorphism,  as  can  our 
inference  algorithm  if  we  restrict  ourselves  to  Hindley-Milner  style  let-polymorphism.  We  leave  polymorphic 
recursive  type  inference  in  the  style  of  [TT94,  RFOl]  as  an  open  problem. 


6  ANSI  C 

In  this  section  we  discuss  some  of  the  issues  in  checking  restrict  in  C99.  restrict  is  useful  in  any  language 
with  updateable  references,  not  just  C,  and  that  several  of  the  issues  in  checking  restrict  in  C99  have  more 
to  do  with  particular  features  of  C99  than  with  programming  language  fundamentals. 
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Names.  In  C,  almost  all  names  refer  to  /-values,  that  is,  re/-types  in  our  notation.  That  means,  for 
example,  if  we  declare 

int  ^restrict  p  =  . . .  ; 

then  p  may  change  during  evaluation,  which  could  change  what  object  p  points  to.  (Recall  that  in  our 
A-calculus  notation,  the  name  x  in  restrict  a;  =ei  in  62  is  an  r- value.)  The  standard  is  imprecise  on  this 
issue,  suggesting  that  while  it  is  invalid  to  update  p  to  point  to  a  different  restricted  value,  it  may  be 
permissible  to  update  p  to  a  different  but  non-restricted  value. 

There  are  several  solutions  to  this  problem.  The  simplest  solution  is  to  require  that  all  restrict-qualified 
pointers  also  be  annotated  with  const,  so  that  they  cannot  change.  An  alternative  is  to  distinguish  between 
reading  and  writing  an  abstract  location  p  in  our  effect  sets,  and  then  prevent  the  user  from  writing  to  the 
location  p  corresponding  to  the  /-value  of  p  with  constraints  of  the  form  wr{p)  ^  L,  where  wr{p)  is  the  effect 
of  writing  to  location  p.  A  third  solution,  and  the  one  most  likely  taken  in  a  C  compiler,  is  to  perform  a 
flow-sensitive  analysis  limited  to  a  single  function  body  to  determine  whether  p  is  updated  to  point  within 
the  same  object  or  whether  it  is  updated  with  a  new  pointer  (e.g.,  p++  versus  p  =  q).  The  former  should  be 
allowed,  and  the  latter  should  be  forbidden. 

Initialization.  Our  A-calculus  syntax  for  restrict  forces  the  user  to  initialize  restricted  pointers  as  soon 
as  they  are  declared.  C99  has  no  such  requirement.  However,  we  feel  that  requiring  restricted  pointers  to 
be  initialized  is  not  much  of  a  burden,  because  the  common  case  for  restrict  is  for  function  parameters, 
and  function  parameters  are  always  initialized. 

Over-Estimation  of  Effects.  The  C99  standard  defines  restrict  in  a  completely  dynamic  fashion.  The 
accesses  to  object  X  within  a  block  B  are  those  that  occur  at  run-time  when  B  is  executed.  Since  our  analysis 
is  static,  we  may  over-estimate  the  set  of  locations  accessed  during  evaluation,  and  hence  we  may  fail  to  type 
check  a  program  that  executes  correctly  according  to  the  standard. 

Arrays.  The  C99  standard  contains  the  following  example  of  a  valid  use  of  restrict  ([ANS99],  page  111): 
void  f(int  n,  int  ^restrict  p,  int  ^restrict  q) 

while  (n —  >  0) 

3|cp++  =  *q++; 

} 

void  g(void)  { 

extern  int  d[100]; 
f (50,  d  +  50,  d) ;  //  ok 

} 

In  this  example,  the  user  has  implicitly  split  the  array  d  into  two  disjoint  smaller  arrays,  and  then  called 
f  knowing  that  as  f  traverses  the  arrays  p  and  q  it  will  only  access  the  first  50  elements  of  each.  In  our 
type  system  this  program  will  fail  to  type  check,  because  this  property — accessing  only  50  elements  of  each 
array — cannot  be  deduced  from  the  type  of  f.  This  application  of  restrict  is  useful  in  C,  and  must  be 
allowed.  We  feel  that  the  best  way  to  handle  this  situation  in  a  manner  consistent  with  C  is  to  force  the 
programmer  to  insert  a  type  cast  at  the  call  to  f  ()  to  tell  the  compiler  that  d  [0 .  . 49]  and  d  [50 .  .  99]  should 
be  treated  as  distinct  objects. 

Escaping  pointers.  The  C99  standard  explicitly  allows  certain  pointers  annotated  with  restrict  to 
escape  the  scope  of  their  declaration.  Specifically,  a  function  whose  body  declares  a  restricted  pointer  p 
may  return  the  value  of  p.  The  only  example  of  this  in  the  standard  is  the  definition  of  a  function  that  returns 
a  pointer  to  a  structure,  one  of  whose  fields  is  annotated  with  restrict.  Thus  the  motivation  for  allowing 
escaping  restricted  pointers  seems  to  be  to  handle  this  case  of  restrict  in  a  structure  declaration.  We 
believe  (see  below)  that  annotating  structure  field  names  with  restrict  is  not  well-defined  in  general.  Thus 
we  do  not  support  this  usage,  and  our  type  system  forbids  restricted  pointers  from  escaping  entirely. 
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Data  Structures.  The  C99  standard  contains  an  example  in  which  a  struct  (a  record  type)  contains  a 
restrict  qualifier  ([ANS99],  page  112): 

typedef  struct  {int  n;  float  ^restrict  v;}  vector; 

This  particular  use  of  restrict  is  easy  to  handle  in  our  system  and  semantically  well-defined,  since  vector 
is  a  shorthand  for  a  pair,  and  thus  we  can  think  of  all  operations  on  vector  as  syntactic  sugar  for  operations 
on  the  individual  elements  of  the  pair.  Thus  we  can  rewrite 

vector  X  =  {  3,  a 

. . .  x.n  . . .  x.v  . . . 

as 

int  x_n  =  3; 

float  ^restrict  x_v  =  a; 

. . .  x_n  . . .  x_v  . . . 

On  the  other  hand,  uses  of  restrict  in  defining  recursive  data  structures  are  problematic.  For  example, 
consider 

struct  list  {int  x;  struct  list  ^restrict  next;  }; 

What  does  restrict  mean  here?  The  problem  is  that  the  name  next  refers  to  a  set  of  (possibly  distinct) 
objects  rather  than  a  single  object  in  memory.  For  example,  if  we  construct  a  circular  list  p,  then  p->next 
and  p->next->next  may  be  the  same.  Is  that  forbidden  by  the  restrict  annotation?  It  seems  not,  because 
both  accesses  go  through  the  name  next.  Clearly,  though,  a  compiler  cannot  use  the  name  next  to  infer 
anything  about  potential  aliasing  of  list  elements. 

A  compiler  needs  stronger  information  than  restrict  to  infer  non-aliasing  of  heap  objects.  One  such 
property  is  linearity  or  uniqueness  [TWM95,  BS96].  A  unique  object  has  at  most  one  pointer  to  it  at  any 
time.  Thus  if  the  next  field  of  struct  list  were  annotated  as  being  unique,  then  a  compiler  could  assume 
(and  enforce)  that  each  element  of  p  is  distinct. 


Modified  Objects.  The  definition  of  restrict  given  in  the  introduction  of  this  paper  is  slightly  simpler 
than  the  standard’s  definition.  Suppose  that  p  is  declared  int  ^restrict  p  and  that  p  points  to  object  X. 
Then  the  standard  states  that  the  restrict  qualifier  is  only  meaningful  if  X  is  modified  within  the  scope  of 
p.  We  refer  to  this  as  the  mod  semantics  of  restrict. 

We  consider  the  mod  semantics  of  restrict  unnecessarily  complicated.  The  main  reason  we  see  to  have 
the  mod  semantics  is  that  for  optimization  purposes  there  is  no  benefit  to  restrict  for  locations  that  are  not 
modified — optimizations  must  preserve  read- write  and  write-write  dependencies,  but  read-read  dependencies 
can  be  safely  ignored. 

However,  from  a  language  design  point  of  view,  it  is  undesirable  to  have  a  construct  that  is  sometimes 
ignored.  This  is  especially  a  problem  if  we  think  of  restrict  as  an  annotation  to  aid  the  programmer. 
For  example,  suppose  we  have  the  declaration  f  (int  ^restrict  a,  int  ^restrict  b).  Is  it  safe  to  call 
f(x,x)?  Under  the  mod  semantics  we  cannot  tell  without  either  an  affects  clause  (see  Section  5.1)  or 
examining  the  source  code  for  f.  We  believe  that  rather  than  use  the  mod  semantics,  we  should  use  our 
semantics  and  simply  remove  restrict  qualifiers  when  they  are  unnecessary. 

However,  it  is  relatively  easy  to  incorporate  the  mod  semantics  of  restrict  into  our  system.  Rather  than 
having  effects  of  the  form  p,  we  split  effects  into  three  kinds:  rd{p),  generated  in  (Deref),  wr{p),  generated 
in  (Assign),  and  rstr{p),  generated  in  (Restrict).  Then  we  split  the  type  rule  (Restrict)  into  two  cases  using 
conditional  constraints: 


F  h  ei  :  re/^(r);  Li 
r[a;  ref^  (r)]  1-62  :  r2;  L2 
p'  ^  Iocs{T,t,T2)  wr{p)  ^  1/2 
wr{p')  &  L2  =>  p  ^  L2 
F  h  restrict  a;  =61  in  62  :  T2; 

Li  U  1/2  U  {rstr(p)} 


(Restrict") 
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Here  p  ^  L  is  shorthand  for  rd{p)  ^  L,  wr{p)  ^  L,  and  rstr{p)  ^  L,  and  similarly  for  p  ^  Iocs{t)  and 
p  ^  locs{T). 

In  (Restrict")  we  use  a  conditional  constraint  to  enforce  the  mod  semantics.  The  constraint  wr{p')  € 
L2  =>  p  ^  L2  is  satisfiable  if  either  wr{p')  ^  1/2  or  p  ^  L2-  In  other  words,  we  only  require  that  p  is  not 
accessed  in  62  if  p'  is  modified. 

Notice  that  in  (Restrict")  we  still  require  that  p'  not  escape  62.  As  before  this  forbids  having  different, 
non-restricted  abstract  locations  corresponding  to  the  same  concrete  location.  Finally,  notice  that  it  is  an 
error  if  p  is  modified  in  62  (formally  wr{p)  £  L2).  This  is  because  if  p  is  modified  in  62,  then  in  the  mod 
semantics  we  also  require  p  ^  L2,  which  is  an  immediate  contradiction. 

For  type  inference  we  proceed  as  before.  We  first  infer  p  annotations.  Next  we  normalize  the  constraints, 
with  the  addition  of  replacing  the  constraints  wr{p')  £  L  p  ^  L  with  wr{p')  £  e  =>  p  ^  e  and  L  C  s. 

Finally,  after  checking  satisfiability  of  the  p  ^  s  constraints,  we  check  the  conditional  constraints.  For 
each  constraint  wr{p')  £  s  =>  p  ^  s,  we  use  the  modified  depth-first  search  procedure  of  Figure  5  to  check 
whether  wr{p')  reaches  e.  If  wr{p')  does  not  reach  e,  then  the  constraint  is  satisfiable.  If  wr{p')  does  reach  e, 
then  the  constraint  is  satisfiable  if  and  only  if  p  ^  e,  which  we  check  with  another  call  to  the  depth-first  search 
procedure.  Since  there  are  0{k)  conditional  constraints,  where  k  is  the  number  of  restrict  annotations  in 
the  program,  this  step  takes  time  0{kn),  where  n  is  the  size  of  the  typed  program.  Thus  the  whole  inference 
algorithm  still  takes  time  0{kn  +na{n)). 

7  Related  Work 

Effect  systems  were  first  described  by  Gifford  and  Lucassen  for  FX-87  [GJLS87,  LG88].  FX-87  includes 
subtyping,  polymorphism,  and  notation  for  declaring  the  effects  of  expressions  [GJLS87].  One  of  the  best- 
known  type  and  effect  systems  is  the  region  type  system  proposed  by  Tofte  and  Talpin  [TT94].  Our  type 
system  bears  some  interesting  similarities  to  region  inference.  The  p  annotations  can  be  thought  of  as  regions, 
and  we  can  apply  the  rule  (Down)  whenever  we  discover  that  a  location  is  purely  local  to  a  lexical  scope  of 
the  computation  [CalOl]. 

As  mentioned  in  Section  5.3,  we  leave  as  an  open  problem  inference  for  our  type  system  with  polymorphic 
recursion.  Given  the  similarities  between  our  type  system  and  Tofte  and  Talpin’s  region  type  system,  we 
believe  that  Tofte  and  Birkedal’s  region  inference  algorithm  [TB98]  can  be  adapted  to  our  type  system. 

Automatic  alias  analysis  has  been  heavily  studied  in  recent  years  [And94,  BCCH94,  CRL99,  DasOO, 
DMW98,  Deu94,  DRS98,  EGH94,  ERDOO,  HTOl,  HP98,  LR92,  SRW99,  SH97,  Ste96,  WL95,  YHR99, 
ZRL96].  Our  type  system  incorporates  may-alias  analysis  to  check  the  correctness  of  restrict  annota¬ 
tions.  The  may-alias  analysis  we  use  is  very  conservative,  and  in  the  future  we  plan  to  extend  our  type 
system  to  use  more  precise  may- alias  analysis. 

The  key  benefit  of  our  type  system  compared  with  a  fully-automatic  alias  analysis  is  that  the  programmer 
has  control  over  the  alias  analysis  and,  by  extension,  any  subsequent  analyses  (e.g.,  optimizations)  based  on 
aliasing  information.  If  the  type  system  rejects  a  restrict  annotation  as  being  inconsistent,  the  programmer 
knows  that  either  their  annotation  is  incorrect  or  the  underlying  may-alias  analysis  is  overly  conservative, 
and  they  can  take  the  appropriate  steps  to  correct  the  problem.  Once  a  program  with  restrict  annotations 
passes  the  type  checker,  the  programmer  knows  at  least  some  of  the  places  where  the  compiler  assumes 
non-aliasing.  We  feel  that  this  exposure  of  aliasing  information  is  helpful  to  a  programmers. 

As  described  in  the  introduction,  one  of  the  most  interesting  properties  of  restrict  is  that  it  lets  us 
locally  recover  the  ability  to  perform  strong  updates  [CWZ90].  We  believe  that  restrict  can  be  added  to 
extend  the  flow-sensitive  type  systems  of  Walker,  Smith,  and  Morrisett  [SWMOO,  WMOO]  and  Vault  [EDOl]. 
In  these  type  systems,  locations  are  either  linear,  which  we  will  indicate  by  1,  or  non-linear,  which  we  will 
indicate  by  u>  [TWM95,  BS96].  In  these  type  systems,  updates  to  linear  locations,  which  represent  a  single 
object,  are  strong  updates,  and  updates  to  non-linear  locations  are  weak  updates. 

In  this  kind  of  type  system  there  is  a  natural  subtyping  relation  1  <  w,  i.e.,  it  is  safe  to  treat  linear 
locations  as  non-linear.  We  can  relate  restrict  to  this  subtyping.  The  Calculus  of  Capabilities  includes  a 
mechanism  to  temporarily  promote  linear  locations  to  non-linear  locations  and  then  recover  linearity  in  a 
continuation  [CWM99].  By  using  restrict  we  can  capture  a  new  and  different  paradigm:  We  can  locally 
downcast  non-linear  locations  to  linear  locations.  The  downcast  from  w  to  1  is  safe  because  of  the  semantics 
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of  restrict.  By  adding  a  restrict  qualifier  to  the  type  of  a  pointer  p  the  programmer  agrees  that  they 
will  only  access  *p  through  the  name  p.  As  long  as  that  agreement  is  valid — i.e.,  within  the  scope  of 
restrict — an  analysis  can  treat  p  as  linear,  and  perform  strong  updates. 

8  Conclusion 

We  have  presented  a  formal  semantics  for  restrict  and  a  type  and  effect  system  for  checking  the  correctness 
of  restrict  annotations.  While  our  type  system  does  not  address  all  the  issues  in  checking  restrict  in 
ANSI  C  programs,  we  believe  that  it  captures  the  key  properties  that  a  restrict  annotation  should  have.  We 
have  shown  that  our  proposed  type  and  effect  system  is  sound  with  respect  to  our  semantics  for  restrict. 
We  have  also  presented  a  type  inference  algorithm  for  restrict  and  described  natural  extensions  of  our 
system  to  include  affects  clauses,  subtyping,  and  parametric  polymorphism. 
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A  Proof  of  Soundness 

In  our  soundness  proof,  we  will  implicitly  extend  typing  judgments  to  values  F  h  u  :  r;  L  in  the  following 
way:  Locations  I  will  be  represented  in  the  proof  as  variables,  and  thus  their  types  will  be  stored  in  F  and 
they  will  typecheck  using  the  rule  (Var).  We  will  implicitly  treat  semantic  integers  as  syntactic  integers,  and 
use  (Int)  to  typecheck  them.  Functions  will  be  represented  not  as  closures  but  as  syntactic  functions,  as  in 
standard  small-step  semantics  subject-reduction  proofs  [WF94].  Thus  semantic  functions  can  be  typechecked 
using  (Lam).  Notice  that  in  the  judgment  F  h  u  :  r;  L,  the  set  L  must  always  be  0,  by  simple  inspection  of 
the  type  rules.  We  will  use  this  property  implicitly  in  our  proof. 

Definition  3  (Compatibility)  We  say  F  and  L  are  compatible  with  store  S,  written  (F,  L)  ~  S,  if 

1.  dom(T)  =  dom(S)  and 

2.  for  all  I  e  dom(S),  there  exist  p,T  sueh  that  F(/)  =  ref^ir)  and 

f  F  h  S{1)  :  r;  0  if  S{1)  ^  err 
y  p  ^  L  if  S{1)  =  err 

Intuitively,  (F,  L)  ^  S  if  an  expression  e  that  typeeheeks  in  environment  F  and  has  effeets  L  ean  he  run  safely 
in  store  S. 

Lemma  4  If  (F,  L  U  L')  ~  S  then  (F,  L')  ~  S. 

Definition  4  (Extension)  We  say  that  (F',5')  is  an  extension  of  (T,S)  if 
1.  dom(T)  =  dom(S)  and  dom(T')  =  dom(S')  and 

^  \dom(r)  ~  ^ 

Definition  5  (Safe  Extension)  We  say  that  (F',  S')  is  a  safe  extension  of  (F,  S),  written  (F,  S)  =>  (T' ,S'), 

if 
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1.  (r',5')  is  an  extension  of{T,S), 

2.  for  all  I  e  dom{S')  —  dom{S),  if  S'{1)  =  err  and  T'{1)  =  ref’ir),  then  p  ^T,  and 

3.  for  all  I  e  dom{S),  if  S'{1)  =  err  then  S{1)  =  err. 

Intuitively,  (F,  S)  =>  (F',  S')  if  the  abstraet  loeations  eorresponding  to  new  err  loeations  in  S'  don’t  appear 
in  F. 

Lemma  5  If  doni{T)  =  doni{S),  then  (F,5)  (F,5). 

Lemma  6  //(F,5)  ^  (F',5')  and  (F',5')  ^  (F",5"),  then  (F,  5)  ^  (F",5"). 

Lemma  7  (p-Renaming)  If  T  \-  e  :  t;  L  and  p'  ^  T,t,L,  then  R(T)  h  e  :  R(t);  R(L)  for  any  substitution 

R  =  [p^  p']- 

Proof:  The  assumption  p'  means  that  p'  is  completely  fresh:  it  is  does  not  appear  anywhere  in  the 

proof  of  F  h  e  :  r;  L.  □ 

Lemma  8  (Substitution)  7/  F  h  u  :  r;  0  and  F[a;  r]  \-  e  :  t';  L,  then  F  h  e[x  u]  :  t';L. 

Theorem  2  (Subject  Reduction)  If  T  \-  e  :  t;  L  and  S  \-  e  ^  r;S',  where  (F,LU  L')  ~  S,  then  there 

exists  F'  sueh  that 

1.  F'  h  r  :  r;  0  (whieh  implies  r  ^  err), 

2.  {T',L')  ~  S',  and 

3.  (F,5)  ^  (F',5') 

Proof:  By  induction  on  the  structure  of  the  proof  S  \-  e  ^  r]  S' .  Recall  that  for  each  rule  of  Figure  2,  there 
are  corresponding  reductions  to  err  for  cases  for  invalid  programs.  Thus  for  each  case  below,  we  will  first 
reason  based  on  the  shape  of  e  to  decide  which  possible  rule  we  used,  and  then  show  that  r  is  not  err. 

(Sub) 

Assume  without  loss  of  generality  that  all  uses  of  (Sub)  are  after  uses  of  (Down).  Observe  that  as  the  last 
step  of  the  proof  F  h  e  :  r;  7/  we  may  have  used  the  rule  (Sub): 

F  h  e  :  r';  7/  r'  <  r  ,  , 

F  h  e  :  r 

By  assumption  we  also  know 

5he^r;5'  (2) 

(F,LU7i')~5'  (3) 

Then  by  (1),  (2),  (3),  and  the  case  analysis  below  (in  which  we  assume  without  loss  of  generality  that 
the  last  rule  applied  was  not  (Sub))  there  exists  a  F'  such  that 

F'hr:r';0  (4) 

(F',L') 

(F,5)^(F',5') 

Then  combining  (4)  and  (1)  we  have 

F'  h  r  :  r; 0 

and  thus  our  conclusion  holds. 

Assume  without  loss  of  generality  that  the  last  rule  applied  in  the  proof  was  not  (Sub) . 
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(Down) 

Observe  that  as  the  last  step  of  the  proof  F  h  e  :  r;  L  —  {pi, . . .  ,p„}  we  may  have  used  the  rule  (Down): 


(5) 


r  h  e  :  r;  L  pi , . . . ,  pn  ^  F,  r 
F  h  e  :  r;  L  -  {pi, . . .  ,p„} 


By  Lemma  1  we  can  assume  that  the  proof  of  F  h  e  :  r;  L  does  not  use  (Down)  as  the  last  step.  We  want  to 
apply  the  case  analysis  below  to  show  our  conclusion,  but  first  we  need  to  do  some  more  work,  because  we 
need  to  know  that  it’s  safe  to  evaluate  an  expression  with  effect  L. 

By  assumption  we  also  know 

5  h  e  ^  r;  5'  (6) 

(F,(L-{pi,...,p„})UL') (7) 

Pick  fresh  p'j , . . . ,  pj^,  that  is,  for  all  i 


p'  ^F,r,L,L' 
P'i  P'j  if  *  i 


(8) 


Let 

i?  =  [pi  p'l , . . . ,  p„  p(j] 

Then  from  (5)  and  Lemma  7  we  have 

i?(F)  h  e  :  R(t);R(L) 

Then  by  (8)  we  derive 

The  :r;i?(L)  (9) 

In  other  words,  because  pi, . . . ,  p„  did  not  escape  the  scope  of  e,  their  names  are  arbitrary,  and  we  can  repeat 
the  typing  proof  of  e  with  any  choice  of  names. 

Now  we  want  to  show 

(F,i?(L)UL')  ~5'  (10) 

Clearly  from  (7)  we  have  dom(T)  =  dom(S),  and  for  all  m  €  dom(S)  there  are  Pm,,Tm,  such  that  F(to)  = 
If  S{m)  ^  err  then  we  are  done,  since  also  from  (7)  we  have  F  h  S{m)  :  0.  So  suppose  that 

S{m)  =  err.  Then  from  (7)  we  know  Pm  ^  {L  —  {pi, . . .  ,Pn})  U  L' .  But  since  pm  G  F  and  p(  ^  F  from  (8) 
we  know  that  p'i  Pm-  Thus 


Pm  ^  (T-{pi,...,p„})U{pi,...,p;,}UL' 

and  therefore  pm  ^  R{L)  U  L' .  Thus  (10)  holds. 

Then  by  (9),  (6),  (10),  and  the  case  analysis  below,  there  exists  a  F'  such  that 

F'  h  r  :  r;  0 

(F',L')  ~  S' 

(F,5)^(F',5') 

Thus  our  conclusion  holds. 


Assume  without  loss  of  generality  that  the  last  rule  applied  in  the  proof  was  neither  (Sub)  nor  (Down) . 

S 

By  assumption  we  have 


Fha;:F(a;);0 

(11) 

Shx^r-,S' 

(12) 

(F,0UL')  ~  S 

(13) 
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By  (13),  dom{T)  =  dom{S),  so  by  (11),  x  €  dom{S).  Therefore  we  must  have  used  the  reduction 

X  e  dom(S) 

S  \-  X  ^  x;  S 

So  r  =  X  and  S'  =  S.  Let  T'  =  T.  Then  our  conclusion  trivially  holds: 

r'  ha;  :  r(a;);0 

(r',L')  ~  S' 

(r,5)^(r',5') 

where  the  last  conclusion  holds  by  Lemma  5. 

E 

Trivial. 


I  ref  e | 

By  assumption  we  have 

r  h  e  :  r;L 
r  h  ref  e  :  re/^(r);  L 

5hrefe^r;5' 

(r,LUL')  ~5 

By  (16)  and  inspection  of  the  semantic  rules,  we  must  have  applied  a  reduction  for  e: 

5h  e  ^re;5' 

By  (15),  (18),  (17),  and  induction,  there  exists  a  r(  satisfying 

Tg  h  re  :  r;  0 

(r,5)^(n,5:) 

By  (19),  re  is  not  err.  Thus  the  reduction  (16)  must  in  fact  be 

5  h  e  re;  5'  I  ^  dom{S'^) 

S  h  ref  e  5' re] 

with  S'  =  S'g[l  re]  and  r  =  I  (see  (16)).  Let 

r' =r',[l^  re  fir)] 


(15) 

(16) 

(17) 

(18) 


(19) 

(20) 
(21) 


(22) 


Clearly 


r'  h  /  :  reff{Ty,9 


Further,  since  by  (22)  we  have  I  ^  dom{S'g),  we  also  have  I  ^  dom(r()  by  (20),  and  therefore  I  ^  dom{T) 
by  (21).  Thus  (r',5')  is  an  extension  of  (r,5).  Further,  since  S'{1)  =  re  err  we  have 


(r;,5:)^(r',5') 


(23) 


Combining  (23)  and  (21)  by  lemma  6,  we  have 


(r,5)^(r',5') 


Finally,  by  (20)  we  also  have 


(r',L')  ~  S' 
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since  I  ^  dom(S'^)  and  ^  err. 
Thus  our  conclusion  holds. 


L!liI 

By  assumption  we  have 

The:  ref''{T)\  L 
r  h  *  6  :  r;  L  U  {p} 

(24) 

5h*6^r;5' 

(25) 

(r,LU{p}UL')  ~5 

By  (25)  and  inspection  of  the  semantic  rules,  we  must  have  a  reduction  for  6: 

(26) 

She^rg-,S'g 

By  (24),  (27),  (26),  and  induction,  there  exists  a  r(  satisfying 

(27) 

Tg  h  re  :  re/^(r);0 

(28) 

(r;,{p}uL')~^: 

(29) 

(r,5)^(r;,5:) 

(30) 

By  (28)  we  know  Vg  is  a  value  and  is  not  err.  By  inspection  of  the  type  rules  we  can  see  that  the  only  type 
rule  that  can  assign  a  value  to  the  type  re/^(r)  is  (Var).  Notice  that  any  uses  of  (Sub)  in  the  proof  (28)  must 
be  trivial,  since  there  is  no  subtyping  under  a  re/ type  constructor.  Therefore  we  see  that  Vg  G  dom(r(), 
hence  Vg  is  in  fact  a  location  and  Vg  G  dom{Sg)  by  (29).  Therefore  the  reduction  (25)  must  in  fact  be 

S\-e^rg;Sg  Vg  e  dom(Sg) 

Sh*e^S'MS'g  ^  ’ 

with  S'  =  S'g  and  r  =  S'g(rg)  (see  (25)).  Let  T'  =  Tg.  Then  clearly 

(r',L')  ~  S' 


by  (29),  and 


(r,5)^(r',5') 

by  (29)  and  (30).  Further,  by  (28)  we  know  r'(re)  =  refir). 
S'(rg)  err  and 

r'  h5'(re)  :r;0 


Then  since  p  G  {p}  U  L',  by  (29)  we  know 


Thus  our  conclusion  holds. 


I  ei  :  =  e2  I 

By  assumption  we  have 

r  h  ei  :  re/^(r);  Li  T  h  62  :  r;  L2 
r  h  ei  :  =  62  :  r;  Li  U  1/2  U  {p} 

5hei  :  =  e2^r;S' 

(r,LiUL2U{p}UL')  ~5 

By  (33)  and  inspection  of  the  semantic  rules,  we  must  have  applied  a  reduction  for  ei: 

5  h  61  Tei  ;  5' J 

By  (32),  (35),  (34),  and  induction,  there  exists  a  satisfying 

^  rg,  : 


(32) 

(33) 

(34) 

(35) 

(36) 
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(n^,L2U{p}UL')~^; 

(37) 

(r,5)^(n^,5;) 

(38) 

By  (36)  we  see  that  Vg^  is  not  err. 
applied  a  reduction  for  62 : 

Thus  by  inspection  of  the  semantic  rules,  in 

(33)  we  must  also  have 

S'g^  h  62  re, ;  5', 

(39) 

By  (32)  and  (38),  we  have 

he2  :r;L2 

(40) 

Then  by  (40),  (39),  (37),  and  induction,  there  exists  a  satisfying 

r' ,  h  re,  :  r;  0 

(41) 

(n^,{p}UL')~^:, 

(42) 

(r'g^,S'J^(T'^^,S'J 

(43) 

By  (36)  we  know  that  is  a  value  and  is  not  err.  By  inspection  of  the  type  rules  we  see  that  the  only  type 
rule  that  can  assign  a  value  to  the  type  re/^(r)  is  (Var).  Notice  that  any  uses  of  (Sub)  in  the  proof  (36)  must 
be  trivial,  since  there  is  no  subtyping  under  a  re/ type  constructor.  Therefore  we  see  that  G  dom(r(J, 
hence  Vg^  is  in  fact  a  location  and  Vg^  G  dom{Sg^)  by  (37). 

Then  by  (43)  we  know  that  rg^  G  dom{Sg^)  and  h  rg^  :  ref^{T).  Then  since  p  G  {p}  U  L' ,  by  (42)  it 
must  be  that  Sg^(rg^)  is  not  err.  Therefore  the  reduction  (33)  must  in  fact  be 

5  h  ei  rei ;  5' ^  5' ^  h  62  ->  rg^ ;  S'g^ 

Tg,  G  dom{S'^^)  ^e,(rei)  err 

5  h  ei  :  =  e2  Vg^]  S'g^[rg^  Vg^] 

where  S'  =  S'g^[rg^  Vg^]  and  r  =  Vg^  (see  (33)).  Let  T'  =  Clearly  we  have 

r'  h  Tg^  :  r;0 


by  (41).  Combining  (43)  and  (38)  we  have 


(r,5)^(n^,5:j  (45) 

Clearly,  then,  (r',5')  is  an  extension  of  (r,5).  And  since  S'{rg^)  =  Vg^  ^  err  by  (41),  we  have 

(r,5)^(r',5') 

Finally,  also  since  Vg^  ^  err  and  since  Vg^  G  dom{S'g^)  and  T'  h  Vg^  :  ref^{T),  from  (42)  and  (41)  we  can 
conclude 

(r',L')  ~  S' 

Thus  our  conclusion  holds. 


restrict  a;  =ei  in  62 
By  assumption,  we  know 

r  h  ei  :  re/^(r);  Li  r[a;  ref^  (r)]  h  62  :  r2;  L2 

_ P'  i  r,r,r2 _ piL2 _ 

restrict  x  =ei  in  62  :  r2 ;  Ti  U  Z/2  U  {p} 

S  h  restrict  x  =ei  in  62  r;  S' 

(r,LiUL2U{p}UL')  ~5 

By  (47)  and  inspection  of  the  semantic  rules,  we  must  have  applied  a  reduction  for  ep. 

S\-  e\  Vg^]  5' j 


(46) 

(47) 

(48) 

(49) 
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By  (46),  (49),  (48),  and  induction,  there  exists  a  such  that 

h  rei  :  re/^(r);0  (50) 

(n^,L2U{p}UL')~^;  (51) 

(r,5)^(r(^,5;)  (52) 

By  (50)  we  see  that  is  a  value  and  is  not  err.  By  inspection  of  the  type  rules  we  see  that  the  only  type 
rule  that  can  assign  a  value  to  the  type  re/^(r)  is  (Var).  Notice  that  any  uses  of  (Sub)  in  the  proof  (50)  must 
be  trivial,  since  there  is  no  subtyping  under  a  re/ type  constructor.  Therefore  we  see  that  G  dom(r(J, 
hence  is  in  fact  a  location  and  G  dom{Sl^)  by  (51).  Thus  by  inspection  of  the  semantic  rules,  in  (47) 
we  must  also  have  applied 


5'ei  [rei  ^  err,  I'  ^  (r^i )]  h  62  [a;  I']  r^^ ; 


(53) 


with 

I'  ^  dom{S'^^)  (54) 

Before  we  can  apply  induction  to  62,  we  need  to  do  a  little  more  work.  Pick  a  fresh  p".  That  is,  pick  a  p" 
such  that 

p'V{p},r,r(^,r,r2,L2,i'  (55) 

Let 

R  =  \p'^  p"] 

Then  by  Lemma  7  and  (46)  we  have 


i?(r[a;  ^  re/^'(r)])  h  62  :  i?(r2);  i?(L2) 


which  by  (46)  is  equivalent  to 

r[a;  ref^  (r)]  h  62  :  T2;  77(1/2) 

Combining  this  with  (52),  we  derive 


ref^  (r)]  h  62  :  r2;  77(1/2) 

Then  by  a-conversion,  since  I'  ^  dom{Sg^)  implies  I'  ^  by  (51),  we  can  rename  x  to  I'  and  derive 

ref^  (r)]  h  62(2;  I']  :  T2;R{L2)  (56) 

Finally,  before  we  can  apply  induction,  we  need  to  show  compatibility  between  the  type  environment  in  (56) 
and  the  store  in  (53) .  But  which  effect  set  should  we  use  for  compatibility?  Clearly  the  set  we  choose  cannot 
contain  p,  because  the  store  in  (53)  contains  a  location  corresponding  to  p  that  maps  to  err.  Thus  we  use 
the  following  set  : 

Lg,  =  {L'  -  {p})  U  77(L2) 

Also  let 

r,,  =r(jr  ^re/^"(r)] 

Re2  =  S'ei  [rei  err,  I'  S'{rg, )] 

where  Tg^  is  from  (56)  and  Sg^  is  from  (53).  Notice  that  Tg^  is  an  extension  of  T^^ ,  since  by  (54)  and  (51) 
I'  ^  .  We  want  to  show 

(re2,7ie2)  ~  /S'es  (57) 

To  see  (57),  first  observe  that  Vg^  G  dom(5'J  by  (50)  and  (51),  and  observe  that  dom(r(J  =  dom{S'g^) 
by  (51),  and  therefore  dom(Tg^)  =  dom{Sg^). 

For  the  second  component  of  compatibility,  pick  any  m  G  dom{Sg^),  and  suppose  re2(TO)  = 
which  holds  trivially  by  (51)  and  the  construction  of  Tg^.  There  are  three  cases: 
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1.  Suppose  TO  =  Tei-  Then  =  p,  and  by  construction  of  we  have  8^2(1^)  =  err.  But  p  ^  L2 
by  (46),  and  since  p”  ^  p  by  (55)  therefore  p  ^  Lg2- 


2.  Suppose  TO  =  I'.  Then  p^  =  p" ■  By  construction  of  8^2  we  have  8e2{m)  =  5'j(rei).  But  by  (50) 
and  (51)  we  have  5'j(rei)  err  and  T^^  h  5'j(rei)  :  r;  0.  But  then  since  Tes  is  an  extension  of  T^^ , 
we  also  have  Tes  h  5' ^  (rei )  :  r;  0. 

3.  Suppose  TO  ^  rei,m  ^  I'.  Then  8e2(m)  =  8g^(m)  and  re2(TO)  =  By  (55),  it  must  be  that 

Pm  p" ■  If  5''j(to)  ^  err,  then  by  (51)  we  have  h  8g^{m)  :  Tm',  %,  and  since  Tes  is  an  extension 
of  we  also  have  Tes  h  8g^{m)  :  Otherwise,  suppose  8g^{m)  =  err.  Then  by  (51)  we  have 

Pm  ^  L2U  {p}  U  I/'.  Thus  clearly  p^  ^  L'  —  {p}.  Since  pm  ^  T2  and  p"  ^  pm,  we  have  pm  ^  R{L2)- 
Therefore  pm  ^  Te2  • 

Thus  (57)  holds. 

Then  by  (56),  (53),  (57),  and  induction,  there  exists  a  such  that 

n,  bre2:r2;0  (58) 

(n^,L'-{p})~5:,  (59) 

(r,,,5ej^(n^,5:j  (60) 

Now  we’re  almost  done.  By  (58)  we  see  that  res  is  not  err.  Combining  this  with  the  fact  that  rei  is  not  err 
(from  (50))  and  with  (49),  (53),  and  (54),  we  see  that  the  reduction  (47)  must  have  been 


5  h  ei  rei;5'j 

Tei  G  dom(5'J  V  ^  dom{8g^) 

S'ei  [rei  ^  err,  I'  ^  8'^^  (re, )]  h  62  [a;  1-^  I']  rg^ ;  8'^^ 
8  h  restrict  a;  =ei  in  62  rgs ; 

S'ejrei  8'^Jl'),l'  ^  err] 

with 

S'  =  S'ejrei  ^  err] 

and 


(61) 


r  =  r 


es 


(see  (47)).  Let  T'  =  r(^.  We  show  the  conclusions  of  the  inductive  hypothesis  one  by  one. 

First,  by  (58)  we  have 

r'hre2:r2;0  (62) 

Next  we  need  to  show 

(r',L')~5"  (63) 

We  proceed  as  in  the  proof  of  (57).  Clearly  dom{T')  =  dom{8l^)  by  (59).  And  by  construction  of  8e2  we 
haverei,r  G  dom{8e2)-  Then  by  by  (60)  we  see  tgi , G  dom{8l^).  Thus  dom{8')  =  dom{8l^)  =  dom(r(^)  = 

dom(r'). 

For  the  second  component  of  compatibility,  pick  any  to  G  dom(8'),  and  suppose  r'(TO)  =  (Tm), 

which  holds  trivially  by  (59).  There  are  three  cases: 


1.  Suppose  m  =  Vei-  Then  8'{m)  =  8g^{l').  Since  8^2(1')  err,  by  (60)  we  see  that  8g^{l')  ^  err. 

By  the  construction  of  Fgs  and  (60)  we  see  that  r(^(/')  =  ref^  (r).  But  then  by  (59)  we  have 
K2  ^  '^62  hence  F'  h  8'{re^ )  :  r;  0. 

2.  Suppose  TO  =  I'.  Then  p^  =  p"  and  8'{l')  =  err.  But  then  by  (55)  we  know  p"  ^  L' . 

3.  Suppose  m  ^  Vei,  m  ^  I'.  Then  8'{m)  =  8g^{m).  Suppose  8g^{m)  ^  err.  Then  from  (59)  we  know 
F'  h  8'{m)  :  Tm',  0-  Otherwise,  suppose  8'{m)  =  8g^{m)  =  err.  There  are  two  cases.  If  to  G  dom{8e2), 
then  TO  G  dom{8')  by  (52).  Then  by  (51)  we  know  pm  ^  L' .  Otherwise,  suppose  to  ^  dom{8e2)-  Then 
by  (60)  Pm  ^  Fes.  But  since  p  G  Fgs  (which  we  can  conclude  from  (50)  and  the  construction  of  Fgs), 
we  know  that  pm  P-  By  (59)  we  have  pm  ^  L'  —  {p},  and  since  Pm  P  see  that  pm  ^  L' . 
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Thus  (63)  holds.  Finally,  we  need  to  show 


(r,5)^(r',5')  (64) 

Clearly  by  (63)  we  have  dom{T')  =  dom{S'),  and  by  assumption  (48)  we  have  dom{T)  =  dom{S).  Also 
by  (52),  construction  of  Fes,  and  (60)  we  see  that  (r',5')  is  an  extension  of  (r,5).  So  we  just  need  to  show 
that  it’s  a  safe  extension. 

Pick  any  m  €  dom{S').  If  S'{m)  ^  err  then  we’re  done.  Otherwise  suppose  S'{m)  =  err  and  r'(TO)  = 
There  are  three  cases: 

1.  Suppose  m  =  Vei-  This  is  impossible,  since  S'{rei)  =  ^  err. 

2.  Suppose  m  =  I'.  Then  I'  ^  dom{S)  by  (54)  and  (52).  So  we  need  to  show  pm  ^  T.  But  pm  =  p"  by 
construction  of  and  (60).  And  p"  ^  F  by  (55). 

3.  Suppose  TO  ^  rei,TO  ^  I'.  Then  S'{m)  =  If  to  €  dom{Sl^)  —  dom{Se^)  then  by  (60)  we  see 

that  Pm  ^  Fes.  But  then  by  construction  of  and  (52)  we  see  pm  ^  F. 

Otherwise  if  to  €  dom{Se^)  then  by  (60)  we  see  that  Se^{m)  =  err.  But  Se^{m)  =  Then 

there  are  again  two  cases.  If  to  €  dom{Sl^)  —  dom{S),  then  by  (52)  we  see  that  pm  ^  F.  Otherwise  if 
TO  e  dom{S)  then  by  (52)  we  see  that  S{m)  =  err. 

Thus  (64)  holds.  Combining  (62),  (63),  and  (64)  we  see  that  our  conclusion  holds. 


Xx.e 

Trivial. 


I  ei  62  I 

By  assumption  we  have 


F  h  61  :  Ti 


F  h  62  :  ri ;  1/2 


F  h  6i  62  :  r2 ;  Ti  U  1/2  U  L 


5  h  6i  62  r;  S' 
(r,LiUL2ULUL')  ~5 


By  (66)  and  inspection  of  the  semantic  rules,  we  must  have  applied  a  reduction  for  6i: 


5  h  6i  —>■  Te^;  5' j 

By  (65),  (68),  (67),  and  induction,  there  exists  a  F^^  satisfying 


(65) 

(66) 

(67) 

(68) 


Fgj  h  re,  ■■  Ti  T2;0  (69) 

(r;^,L2ULUL')~^:,  (70) 

(r,5)^(r(^,5;)  (71) 

By  (69)  we  know  that  re,  is  a  value  and  is  not  err.  By  inspection  of  the  type  rules  we  see  that  the  only  type 
rules  that  can  assign  a  value  to  the  type  ri  T2  are  (Var)  and  (Lam) ,  possibly  followed  by  an  application 
of  (Sub).  But  by  (70)  we  know  that  F^^  assigns  only  reference  types.  Thus  the  proof  (69)  must  in  fact  be 


r[a;  r(]  h  6  :  T/ 

F  h  Xx.e  :  t[  — 4  0 

Ti  <  Tj  <  r2  Lf  C  L 

F  h  Xx.e  :  ti  r2;  0 


(72) 


where  re,  =  Xx.e. 
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Further,  by  inspection  of  the  semantic  rules,  in  (66)  we  must  also  have  applied  a  reduction  for  62: 


5' j  \-  62  ^  res  ;  5'es 

(73) 

By  (65)  and  (71),  we  have 

Fej  1-62  :  ri;7/2 

(74) 

Then  by  (74),  (73),  (70),  and  induction,  there  exists  a  satisfying 

Tes  1“  Gs  :  n;0 

(75) 

(r;^,LuL')~5; 

(76) 

(77) 

From  (75)  we  know  that  is  not  err.  Thus  by  inspection  of  the  semantic  rules,  in  (66) 

we  must  also  have 

applied  a  reduction  for  e\x  i-^-  res]: 

5es  b  e[x  ^  res]  -^re;S'^ 

(78) 

Combining  (71)  and  (77)  we  see 

(r,s)^(r',^,s'j 

(79) 

Now  by  (72)  and  (79)  we  see  that 

Teslas  H-  r(]  h  6  :  r2;L/ 

(80) 

where  Lf  C  L.  By  (75)  and  ri  <  t[ 

from  (72)  we  see  that 

Tes  ^  Gs  :  ^];0 

(81) 

Then  by  (80),  (81),  and  Lemma  8  we  have 

Tes  ^  e[a;  res] 

(82) 

From  (76)  we  have 

(r;s,T/U(L-L/)UL')~5:, 

(83) 

Now  by  (82),  (78),  (83),  and  induction,  there  exists  a  r(  satisfying 

Fg  h  re  :  Tj ;  0 

(84) 

(r;,(L-L^)UL')~5: 

(85) 

{K,,s'j^{r'„s'j 

(86) 

where  r  =  and  5  =  5'  (see  (66)).  Let  F'  =  r(.  Then  clearly  since  Tj  <  by  (72)  we  have 


F'  h  r  :  r2 ;  0 

from  (84).  Then  we  also  have 

(r',L')  ~  S' 

from  (85).  Finally,  we  get 

(r,5)^(r',5') 

combining  (79)  and  (86).  Thus  our  conclusion  holds. 


□ 

Given  the  subject-reduction  theorem,  soundness  is  easy  to  show: 

Theorem  3  7/  0  h  e  :  r;  L,  then  0  h  e  r;  S' ,  where  r  is  not  err 

Proof:  First  observe  that  (0,  L)  ~  0.  Then  in  our  semantics  every  term  can  be  reduced  to  some  result  r. 
By  the  subject-reduction  theorem,  there  is  a  F'  such  that  F'  h  r  :  r;  0.  Thus  r  is  not  err.  □ 
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